JetBrains: «Дать ИИ то, что стоит усиливать» — три приоритета для технических лидеров
Краткое содержание
Французская версия поста JetBrains для технических лидеров. Главный тезис: «ИИ не выравнивает команды — он усиливает то, что в них уже есть». Опорное исследование — DORA 2025 (AI capabilities model): лучшие команды извлекают больше выгоды, у слабых проблемы становятся виднее. GitClear, январь 2026: на выборке 2 172 недель разработки регулярные пользователи ИИ выдают примерно на 320% больше «устойчивого кода», и выработка тех же команд выросла на 25% между 2024 и 2025. Не сам ИИ создал разрыв — он подсветил существующую разницу.
Три приоритета для лидеров.
Первый — ужесточить code review. ИИ позволяет писать больше кода быстрее, но это полезно только если ревью успевает. LinearB Engineering Benchmark Report 2026: PR с ИИ-кодом ждут ревью в 2,5 раза дольше; если код писал агент автономно — в 5,3 раза. Действия: фиксировать максимальный размер batch-PR (DORA: малые партии — лучшая защита от непросматриваемого пакета), сделать статический анализ настоящим барьером, а не подсказкой. Исследование 4,7 млн проблем качества в 36 000 PR (2019) и его подтверждение январём 2026 для AI-генерированного кода показывают, что только субъективные оценки ревьюера не отличают качественный PR от некачественного.
Второй — дисциплина по техдолгу. GitClear (211 млн строк, 2020–2024): объём изменений вырос на 84%, рефакторинг упал с 25% строк изменений в 2021-м до менее 10% в 2024-м; дубликатов кода в 2024 в 10+ раз больше, чем в 2022. Faros AI 2025 (10 000+ разработчиков): команды, перешедшие от низкого ИИ-усвоения к высокому, получили +9% багов на разработчика, PR в среднем на 154% больше и время ревью +91%. Carnegie Mellon 2025 (806 команд против 1 380): после внедрения warnings статического анализа выросли примерно на 30% и остались, когнитивная сложность кода — примерно +41%. Действия: явно бронировать слот спринта под техдолг, картировать «knowledge risks» (где разработчик не рискнёт менять без долгого изучения) и приоритизировать рефакторинг/документацию/ротацию ревьюеров.
Третий — судейское мастерство разработчика. Anthropic RCT (январь 2026): джуниоры, делегировавшие генерацию кода ИИ и сразу шедшие дальше, набрали 24–39% на тесте понимания; те, кто использовал ИИ активно развивая понимание, — 65–86%. «Productivity gains may come at the expense of the skills needed to validate AI-generated code». Sergio Pellegrino-style «seniority-biased technology shift»: сеньоры выигрывают, потому что у них уже есть judgement; джуниорам ИИ становится тормозом. Стэнфордское Digital Economy исследование 2025: −16% относительной занятости у 22–25-летних в AI-затронутых профессиях. LeadDev 2025: 38% engineering-менеджеров считают, что ИИ сократил прямое менторство юниоров. Действия: пересмотреть стратегию найма джуниоров под перспективу «откуда возьмутся сеньоры через 4 года», сократить «mentor gap», нанимать по способности судить ИИ-вывод, а не по знанию инструментов ИИ.
«Тактический совет»: задавайте направление, не инструменты. Stack Overflow 2025: «autonomy and trust» — главный фактор удовлетворённости. Harness 2025: 52% разработчиков не используют ИИ-инструменты, выданные IT-отделом. Не навязывайте модель, не навязывайте ассистента — стандартизируйте только слой доступа.
# Иллюстрация «AI как лупа», а не «AI как кросс-проверка»:
# джуниор, удерживающий понимание + ИИ
def parse_log_line(line: str) -> dict[str, str]:
"""Парсит строку лога вида '<ts>|<level>|<msg>'."""
ts, level, msg = line.split("|", 2)
return {"ts": ts.strip(), "level": level.strip(), "msg": msg.strip()}
# Прежде чем принять автодополнение ИИ, джуниор задаёт три вопроса:
# 1) Что если в msg есть символ '|'? — параметр maxsplit=2 защитит.
# 2) Что если line пустая? — split вернёт ValueError на распаковке.
# 3) Какие невалидные строки возможны? — лог-формат не свободный.
import pytest
def test_parse_log_line_handles_pipes_in_message():
out = parse_log_line("2026-05-12T10:00:01|ERROR|connection failed: host|22")
assert out["msg"] == "connection failed: host|22"
def test_parse_log_line_raises_on_empty_input():
with pytest.raises(ValueError):
parse_log_line("")
Значимость
Самая полезная для технических лидеров часть — конкретная подборка свежих исследований (DORA 2025, GitClear 2025/2026, LinearB 2026, Faros AI 2025, CMU 2025, Anthropic 2026, Stanford Digital Economy 2025, LeadDev 2025, Stack Overflow 2025, Harness 2025). Тезис «AI усиливает существующее» — в одной фразе формулирует то, что часто прячется за маркетинговой рамкой «AI делает всех продуктивнее». Слабая сторона — финал поста очевидно сводит рекомендации к экосистеме JetBrains (All Products Pack, ACP-совместимость, Qodana), но это естественно для корпоративного блога. Политической нагрузки нет.
🧾 Транскрипт (формат)
Donner à l’IA quelque chose qui mérite d’être amplifié : trois priorités pour les responsables techniques Source: https://blog.jetbrains.com/ai/2026/05/donner-a-l-ia-quelque-chose-qui-merite-d-etre-amplifie-trois-priorites-pour-les-responsables-techniques
La plupart des organisations demandent ce que l’IA peut faire pour leurs développeurs. Une question plus complexe est : qu’est-ce que vos développeurs apportent à l’IA ?
Le rapport 2025 sur le modèle des capacités de l’IA de DORA soutient que l’IA ne nivelle pas les équipes ; elle amplifie ce qu’elle y trouve. Les organisations les plus performantes en tirent davantage parti, tandis que les faiblesses des équipes en difficulté deviennent plus visibles.
Il semble qu’il en va de même au niveau individuel. L’analyse de GitClear de janvier 2026 portant sur 2 172 semaines de développement a révélé que les utilisateurs réguliers de l’IA produisaient environ 320 % (4,2 fois) plus de code durable que les non-utilisateurs. Ces mêmes utilisateurs ont également augmenté leur production de 25 % entre 2024 et 2025. Il s’agit d’une amélioration significative, mais qui n’explique pas à elle seule l’ensemble de l’écart. La conclusion de GitClear est que l’IA a accentué une différence de performance qui existait déjà. Les ingénieurs expérimentés et très productifs ont souvent été les premiers à adopter l’IA.
Cela compte, car l’IA ne fonctionne pas dans le vide. Elle vient se superposer aux habitudes, systèmes et contraintes déjà présents dans votre équipe. Si les fondations sont solides, l’IA peut aider. Si elles sont fragiles, l’IA donne simplement plus d’espace aux faiblesses pour se propager.
Certaines de ces fondations sont faciles à voir. L’infrastructure apparait sur votre bilan et les outils peuvent être inventoriés. Cet article se concentre sur trois domaines plus faciles à négliger : la révision du code, la dette technique et le jugement des développeurs. Ces problèmes ne sont pas nouveaux, mais l’IA les rend plus faciles à ignorer tout en rendant leurs conséquences plus difficiles à éviter.
Priorité n° 1 : renforcer la révision du code L’IA permet aux développeurs d’écrire plus de code plus vite, mais cela n’est utile que si le processus de révision peut gérer le volume supplémentaire. Si le pipeline de révision est déjà sous pression, l’IA ne résout pas le problème : elle envoie simplement plus de code dans le même goulot d’étranglement. Des lots de modifications plus importants arrivent plus rapidement, la responsabilité devient plus floue et les révisions se limitent à repérer les signaux d’alerte évidents au lieu de comprendre globalement les changements.
Les données le montrent déjà. Le Rapport 2026 sur les benchmarks en en ingénierie logicielle de LinearB a constaté que les pull requests contenant du code assisté par IA attendaient environ 2,5 fois plus longtemps avant d’être révisées que celles écrites sans IA. Lorsque les agents d’IA avaient écrit le code de manière autonome, ce délai montait à 5,3 fois plus. Leur explication est simple : les développeurs hésitent à prendre en charge une tâche de révision perçue comme plus longue et plus risquée.
Le problème ne vient donc pas seulement du volume. C’est le volume combiné à l’incertitude, injecté dans un processus qui n’a pas changé.
C’est pourquoi la réponse réside dans les processus, pas dans les effectifs.
Prochaines actions à envisager :
Mettre en place ou resserrer votre norme de taille de lot maximale pour les pull requests. DORA a déterminé que les petits lots formaient l’une des meilleures protections contre les pavés de code difficiles à réviser, et l’IA facilite la création de ces pavés. Faire de l’analyse statique une véritable barrière, pas une suggestion. Les évaluations des réviseurs ne permettent pas à elles seules de distinguer de manière fiable les pull requests de haute qualité des autres. Une étude de 2019 portant sur 4,7 millions de problèmes de qualité du code dans 36 000 pull requests a montré que les pull requests acceptées et rejetées se ressemblaient étonnamment sur le plan des indicateurs de qualité. Une étude réalisée en janvier 2026 a confirmé ce schéma pour le code généré par IA. L’analyse statique réduit la part de subjectivité dans la décision d’accepter ou non une modification. Priorité n° 2 : faire preuve de discipline en matière de dette technique L’IA peut aider à réduire la dette technique existante, à améliorer la documentation, à ajouter des tests et à effectuer un nettoyage répétitif. Mais elle peut aussi faciliter l’accumulation d’une nouvelle dette plus rapidement que la base de code ne peut l’absorber. Trois séries de données indépendantes vont dans ce même sens.
L’analyse longitudinale de 211 millions de lignes de code réalisée par GitClear en 2025 a révélé que le volume de modifications du code a augmenté de 84 % entre 2020 et 2024. La refactorisation a fortement chuté, passant de 25 % des lignes modifiées en 2021 à moins de 10 % en 2024. On trouve plus de 10 fois plus de blocs de code dupliqués en 2024 qu’en 2022. GitClear relie ces changements à l’essor de la programmation assistée par IA après 2022. L’analyse de télémétrie réalisée par Faros AI en 2025, portant sur plus de 10 000 développeurs a révélé que les équipes passant d’une faible adoption de l’IA à une forte adoption de l’IA ont constaté 9 % de bugs supplémentaires par développeur, des pull requests d’une taille supérieure de 154 % en moyenne ainsi que des délais de révision allongés de 91 %. La production individuelle a augmenté, mais pas la performance organisationnelle. Une étude réalisée en 2025 par Carnegie Mellon a abouti à des conclusions similaires. Les chercheurs ont suivi 806 équipes ayant adopté un outil de programmation par IA et les ont comparées à 1 380 équipes qui ne l’avaient pas fait. Les avertissements de l’analyse statique ont augmenté d’environ 30 % après l’adoption et sont restés élevés. La complexité cognitive a augmenté d’environ 41 % et est restée élevée, même après la prise en compte de la croissance de la base de code par les chercheurs. Le code n’était pas juste plus volumineux, il était aussi plus difficile à comprendre.
Le schéma est difficile à ignorer : la production augmente plus vite que les mécanismes de contrôle de la qualité qui l’entourent.
Cela n’implique pas que les équipes ont besoin de moins d’IA. Cela signifie qu’elles ont besoin de plus de discipline dans l’allocation de leur temps.
Prochaines actions à envisager :
Protéger explicitement la capacité de sprint pour réduire la dette technique. Si l’IA augmente la pression pour livrer rapidement, alors la refactorisation et l’analyse statique deviennent plus importantes, pas moins. Cartographier les risques liés aux connaissances avant que l’IA ne les aggrave. Demandez à vos développeurs quelles parties du code ils hésiteraient à modifier sans une longue phase d’apprentissage. Utilisez ces informations pour prioriser la refactorisation, la documentation et la rotation volontaire des réviseurs. Priorité n° 3 : donner un terrain d’expérimentation au jugement des développeurs Une meilleure révision du code et une meilleure discipline en matière de dette technique dépendent d’un élément plus fondamental : des personnes capables de réellement comprendre ce qu’elles regardent. Cette compétence n’arrive pas automatiquement, et l’IA permet d’éviter plus facilement de la travailler.
L’essai contrôlé randomisé réalisé par Anthropic en janvier 2026 rend ce risque concret. Les chercheurs ont réparti des développeurs juniors apprenant une nouvelle bibliothèque Python en deux groupes, l’un assisté par IA, l’autre codant manuellement. Les développeurs qui avaient délégué la génération de code à l’IA avant de passer à autre chose ont obtenu un score compris entre 24 % et 39 % lors d’une évaluation ultérieure de leur compréhension. Les développeurs qui avaient utilisé l’IA tout en développant activement leur compréhension ont obtenu un score compris entre 65 % et 86 %. La conclusion d’Anthropic est sans détour : « Les gains de productivité peuvent se faire au détriment des compétences nécessaires pour valider le code écrit par l’IA ». Le CTO d’Azure et vice-président de la communauté des développeurs de Microsoft a décrit ce constat comme un « changement technologique biaisé par l’ancienneté ».Les ingénieurs seniors en bénéficient, car ils ont déjà le jugement nécessaire pour orienter, vérifier et intégrer les résultats de l’IA. C’est rarement le cas des ingénieurs moins expérimentés. Pour eux, les mêmes outils peuvent devenir un frein plutôt qu’un levier.
Cela crée une logique tentante à court terme : embaucher des profils seniors, automatiser les tâches confiées aux juniors et passer à autre chose. Cela peut sembler pertinent pendant un trimestre ou deux, mais cela risque aussi de vider le pipeline dont vous aurez besoin à l’avenir. Le jugement qui rend l’IA utile doit être développé avant d’être amplifié.
Prochaines actions à envisager :
Réexaminer votre stratégie de recrutement junior sous l’angle de la continuité métier. D’où viendront vos développeurs seniors dans quatre ans ? Une étude de Stanford Digital Economy de 2025 a révélé une baisse relative de l’emploi de 16 % parmi les personnes âgées de 22 à 25 ans dans les professions exposées à l’IA, même après la prise en comte des tendances d’embauche plus générales. Réduire le déficit de mentorat créé par l’IA. Le rapport 2025 sur l’impact de l’IA de LeadDev a révélé que 38 % des responsables d’ingénierie estimaient que les outils d’IA avaient réduit le mentorat direct pour les ingénieurs juniors. Ce transfert de connaissances ne se fait pas tout seul lorsque les deux parties ont un assistant d’IA sous la main. Sélectionner et intégrer les candidats en fonction de leur capacité de jugement de l’IA, et non pas seulement de leur connaissance des outils d’IA. La question n’est plus de savoir si quelqu’un utilise l’IA, mais s’il sait quand ne pas le faire.
Remarque tactique : définissez l’orientation, pas les outils La façon d’appliquer ces priorités a son importance. Les développeurs ressentiront la différence entre le leadership et le contrôle. L’enquête 2025 de Stack Overflow auprès des développeurs a révélé que « l’autonomie et la confiance » étaient les principaux facteurs de satisfaction professionnelle des développeurs.
On retrouve cette même envie d’indépendance dans le choix des outils d’IA. Le rapport 2025 sur l’état de la livraison de logiciels de Harness a révélé que 52 % des développeurs n’utilisent pas les outils d’IA fournis par leur service informatique. Ce n’est probablement pas sur ce point qu’il faut tenter d’imposer une standardisation.
N’imposez pas un choix de modèle. N’imposez pas un assistant. Vos normes doivent concerner la couche d’accès.
Offrez à votre équipe un espace de travail compatible avec tous les outils d’IA Les JetBrains IDEs offrent à vos développeurs un environnement cohérent pour travailler avec pratiquement n’importe quel LLM ou agent de programmation compatible avec l’ACP. Cela leur permet d’essayer de nouveaux outils sans avoir à reconstruire leur workflow à chaque évolution du marché.
Sous cette flexibilité se cache quelque chose de plus stable : le modèle structurel de l’IDE pour votre base de code. Il n’essaie pas de deviner pas ce que le code peut signifier. Il comprend réellement le code en tant que tel. Si l’IA génère quelque chose de plausible mais qui casse quelque chose ailleurs, l’IDE peut le signaler avant que la modification arrive en révision. Ajoutez JetBrains Qodana, et ce même modèle structurel s’étend à l’analyse statique continue de l’ensemble de votre base de code.
Le point essentiel, en pratique : standardisez seulement que ce qui doit l’être, et préservez la flexibilité pour le reste. Le All Products Pack s’inscrit dans la même logique. Il inclut tous les IDE JetBrains dans un seul abonnement, chacun étant conçu pour un langage majeur utilisé aujourd’hui ou nécessaire demain. Lorsqu’un développeur change de stack, il n’y a ni demande de licence, ni délai d’approvisionnement, ni nouveau cycle d’approbation.
La décision est déjà prise. Les outils sont déjà là.
En savoir plus sur le All Products Pack.
Auteur de l’article original en anglais :
Colette Des Georges